オーロラは雲の上 — RDBのScalabilityとAvailability

Amazonは、なぜ、Aurora（オーロラ）という名前をつけたのだろう？　僕は、どこかで見かけた、「それは、オーロラは雲（Cloud）の上にあるからさ」という一節が、とても気に入っている。

まさに、Auroraの最大の特徴は、Amazonのクラウド・サービスの上に構築されたデータベースであるというところにある。小論では、クラウド上（「雲の上」）のデータベースであるAuroraが、どのようにクラウドの機能を利用しているのかを、そのScalabilityとAvailabilityに焦点を合わせて紹介しようと思う。

AuroraのScalabilityとAvailability

まず最初に、Auroraの主要なScalabilityとAvailabilityを確認しておこう。

Scalability

• Push-button Compute Scaling：コンソール画面で数クリックするだけで、CPU数・メモリーサイズをスケール・アップ／スケール・ダウン出来る。所要時間は、数分。
• Storage Auto-scaling：Auroraでは、ストレージ容量を指定する必要はない。最初10Gのストレージが割り当てられ、以降、必要に応じて、自動的に10G単位で容量は増えていく。ユーザーは、ストレージの容量を意識する必要はない。最終的には、64Tまで拡張可能である。
• Amazon Aurora Replicas：Auroraでは、同じデータベース・ストレージを共有する読み出し専用のRead Replicaを15台まで、数クリックで、瞬時に増設できる。

Availability

• ストレージは自動的に3つのAWS アベイラビリティゾーン (AZs)内に複製され、さらに各AZ内で２つのコピーを作成する。
• 6つのディスクの内少なくとも4つのディスクに書き込みが完了するとすぐに次の処理を実行する。
• 2つのディスク障害までは書き込みは継続し、3つのディスクが障害を起こしても読み込み処理を続ける。
• インスタンス障害が発生した場合、障害の発生していないAZへリカバリを行う。

EC2上に手動でMySQLをインストールした場合を考える

Auroraがいかに、Amazonのクラウド・サービスを利用しているかを見るために、EC2上に手動でMySQLをインストールし、データベースを動かした場合を考えてみよう。

EC2のインスタンスは、通常、EBS(Elastic Block Store)をルートにマウントして、そのOSのファイルシステムとして利用する。MySQLのデータベース・ファイルやログ・ファイルは、このEBS上のファイルシステムに作成されることになる。MySQLのパフォーマンスに大きな影響を与えるbuffer領域は、EC2インスタンスのメモリー上に確保される。

いったん、EC2インスタンスとEBSのタイプ（と大きさ）を選べば、それを途中で変更することはできない。こうした制約は、オンプレミス環境で、物理サーバーにMySQLをインストールして使う時の制約と同じである。ただ、ESBは、EC2インスタンスが属するAvailability Zone(AZ)内に、複数のレプリカを持つ。クラウド上にMySQLデータベースを構築したメリットは、クラウド利用の一般的なメリットを除けば、クラウド上のファイルシステムEBSのAvailabilityの高さに帰着する。

Scale-Outアーキテクチャー

ただ、そのメリットを、少なくともクラウド技術者は、過小に評価してはいけないと思う。クラウドを使う利用者にとっては、クラウドが常に動き続けること、また、データが失われることがないことは、当たり前のように思われるかもしれない。しかし、クラウドを作る側にとっては、それは簡単なことではないからだ。

高い信頼性を持つシステムを作るのには、二つのアプローチがある。一つは、Scale-upで、故障率の低い高機能・高性能なマシンを使うことだ。それには高い費用がかかる（クラウドでインスタンスのコア数やメモリーを増やすことをScale-upということもあるが、それとは違う）。もう一つのアプローチは、Scale-outで、コモディティ化した安価なマシンをたくさん並べて、その計算パワーを引き出す道だ。クラウドは、このScale-outの道を選ぶことで、クラウド・サービスの低価格化に成功した。両者は、価格的には、超高級車と軽自動車ほども離れている。

ただScale-outには、大きな困難な課題がある。安いマシンを使うということは、それだけマシンが壊れやすいということだから。

クラウドに興味を持った頃に出会った、GoogleのPlatform ArchitectだったBen Jaiの次のような発言は、僕に強烈な印象を与えた。「3-year MTBFだとしても, 1000台のうち一台は、毎日だめになるという計算になる。最小のGoogleのアプリケーションでも、2000台のマシンを必要とする。こうした障害をソフトでどう対応するか？　データの多重化と冗長化は、この規模ではどうしても必要となる。」「だから、なぜ、高価な信頼性の高いハードが欲しいなどと思い悩むのか?　信頼性の高いハードは、ソフトウェア技術者を怠け者にする。障害に強いソフトウェアが、安いハードを役に立つものに変えるのだ。」 そして、彼らは実際に、そういうシステムを作り上げたのだ。

データ・ノードの多重化

GFS(Google File System)では、次のように複数のレプリカにデータを多重化する。難しいのは複数のレプリカのデータを更新する書き込みの場合だ。GFSサーバーは、実は、データの転送には関わらない。クライアントにレプリカの位置を知らせるだけだ。データの転送はクライアント自身が行う。ただし、クライアントは、レプリカのディスクにではなくメモリー・バッファーにデータを書く。あとは、各レプリカがメモリー・バッファーの内容を自身のディスクへの書き出すのに責任を持つ。(Googleのファイル・システムは、現在では、マルチ・マスターのGFS2/Colossusに変わっている。)

こうしたデータ・ノードの多重化は、Amazonに限らず、Scale-outのアプローチを取るすべてのクラウドで行われている。次の図は、Azureでのそれを図式化したものである。ここでも、データのreadとwriteでは、振る舞いが異なることに注意しよう。

Gmail, Calendar, Android Play Market, Google AppEngine 等にサービスを提供していたGoogle MegaStoreは、三つのデータセンターをまたいで、９つのレプリカを持っている。こうした形でのAvailabilityの確保は、クラウド技術の中核の一つである。

少し長くなったが、手動でMySQLをクラウドにインストールしたとしても、クラウドである事のメリットは受けられるということである。

Amazon RDS for MySQLを使う

ただ、Amazonのクラウド上にデータベースを構築しようと思ったら、留意すべきことがある。AWSでは、クラウド上にデータベースを構築するための特別のサービスが用意されていることだ。Amazon Relational Database Service (Amazon RDS)がそれである。手動インストールも結構だが、それを使わない手はない。AWSでMySQLを使おうと思ったら、Amazon RDS for MySQLを使うのがいい。（ただし、Auroraの登場で、状況は大きく変わったのだが。AuroraとAmazon RDS for MySQLの違いについては、後で述べる。）

「Amazon RDS を使用すると、コスト効率が良く、サイズ変更が可能なハードウェア容量で、拡張性ある MySQL を数分でデプロイすることができます。バックアップ、ソフトウェアのパッチ適用、監視、縮小・拡張、およびレプリケーションなど、時間のかかるデータベース管理タスクは Amazon RDS が管理するので、お客様はアプリケーション開発に集中することができます。」

Amazon RDS for MySQLでは、Auroraの特徴である、自動バックアップもボタンを押すだけのスケーリングも、レプリカのマルチAZへの配置も、可能なのだ。Amazon RDS for MySQLの概要は、先のリンクを参照されたい。

Amazon RDSとSOA

Amazon RDSは、現在、MySQL、Oracle、SQL Server、PostgreSQLの４つのデータベースに対してサービスが提供されている。Auroraは、Amazon RDSの５番目の利用例となる。利用できるサービスの詳細は、各データベース・エンジンごとに異なるのだが、多くの場合、次のようなサービスを提供しているようだ。

• パラメータの事前設定
• メトリックスの提供とモニタリング
• ソフトウェアの自動パッチ適用
• 自動バックアップ DB
• スナップショット
• 複数アベイラビリティゾーン（マルチ AZ）配置
• 汎用／プロビジョンド IOPS（SSD）ストレージの提供

重要なことは、データベース・エンジンに応じて提供される機能に違いがありながらも、Amazonが、それを Amazon Relational Database Service として、一つのサービスとして扱っているところにあると、僕は考えている。それは、既存のハードウェア・プラットフォームやOSや利用するアプリケーションの違いを超えて、クラウド自体を、ネットワーク上の様々なサービスの組み合わせによって、新しい統一的なサービスを提供するものとして再構成しようという志向を表している。こうした考え方は、SOA(Service Oriented Architecture)と呼ばれるものだ。

AuroraとAmazon RDS for MySQLの違いを考える

Auroraは、正式には、Amazon RDS for Auroraという。それは、MySQL 5.6とフルコンパチのデータベース・エンジンだという。それでは、Amazon RDS for AuroraとAmazon RDS for MySQLとは、どこが違うのだろうか？　一口にいうと、Amazon RDS for AuroraとAmazon RDS for MySQLは、SQLエンジンは同一でも、Amazon RDSの果たしている役割が全く違うのである。Auroraは、Amazon RDSの新しい機能拡張の試みという大きな特徴を持つ。

それでは、何のためにRDSの機能を拡張するのであろうか？　それは、クラウド上でのリレーショナル・データベース向けのサービスであるRDSの上に、各種のSQLのエンジンをのっければ、それが、クラウドの諸機能を十分に活用できるようにするためである。次の図を見てほしい。

データベースというソフトウェアは、特定のOS、特定のハードウェア、特定のファイルシステムの上で動くようにセットアップされたアプリケーションなので、データベースに必要な諸機能、SQL・Transaction・Caching・Loggingといった機能は、一体のものとして構築されている。それは、"Monolithic（一枚岩）"といっていいものだ。逆にいえば、従来の環境では、"Monolithic"じゃなければ、完結したアプリとしては動かないということになってしまうのだから、それはしかたない。

ところが、雲の上にオーロラがあるように、クラウドの上にデータベースがあることを前提に、この"Monolithic"なアーキテクチャーを眺めると、いろいろ無駄（データベースの機能とクラウドの機能がダブっている）や不十分ななところ（クラウドの機能をデータベースが使っていない）があることに気づく。Aurora以前の Amazon RDSは、少し遠慮がちに、クラウド利用を想定していない"Monolithic"なデータベースに、その外側から、Availabilityの高いクラウド・ストレージの利用を中心に、便利なクラウド・サービスを提供しようというものだ。

Auroraのアーキテクチャーは、それとは、全く異なっている。データベースの諸機能のうち、CacheとLoggingの機能を切り出し、それをクラウドのストレージ機能と一体なものにして、新しいクラウド・データベースのサービスを作ったのだ。それが、Amazon RDS for Auroraである。文字通り、「Auroraは雲の上」なのである。

こうした、データベースの"Monolithic"なアーキテクチャーからService Oriented Architectureへの変更は、また、AWS上の様々なサービスとの柔軟な連携の道を開くことになる。

Auroraの心臓部 -- Log-structured Storage

ただ、Auroraは、既存のクラウド・サービスの組み合わせでできているわけではない。Re:InventでのAuroraについてのGuptaのセッション・スライドを眺めていて、驚いたことが一つある。それは、Auroraがデータベースのストレージに、Log-structured Storageを使っているという一節を見つけたときだ。先の図で、"Logging + Storage"と書かれている部分である。

そうなのだ。Log-structured Storageを使っていることを踏まえなければ、Auroraの障害からの"Quick Recovery"のメカニズムも、S3へのBack-upが、何故に"Continuous"に可能なのかも理解できないのだ。また、Auroraでは、ストレージはSSDのみで、磁気ディスクのサポートがないのだが、これも単なる高速化のためではないはずだと思う。Log-structured Storageは、ストレージがSSDの時に、最大の効果を発揮するからだ。

データベース技術としてのAuroraが、極めてイノベーティブなのは、大量のキャッシュとSSDストレージが利用可能な時代に、最適なデータベースのストレージの構造を提案していることだと思う。AuroraのRelational Database Serviceの技術的な心臓部分が、このLog-structured Storageである事は間違い無いと思う。この試みは、画期的であるといっていい。

残念ながら、AuroraのLog-structured Storageについて、僕は、ほとんど情報をもっていない。ここでは、その元となっているLog-structured File Systemについて、簡単に紹介するにとどめたい。

Log-structured File Systemとは何か？

Logでは、ファイルへの書き出しは、常に、ファイル末尾への追加である。Log-structured File Systemは、これと同じように、ファイル・システムへの書き出しが、常に、ストレージの「末尾」への追加であるように、ファイル・システムを構築しようとする。

現代のほとんどすべてのOSでもデータベースでも、データの保持と整合性の確保のために、ファイルとLog（「ジャーナル・ファイル」と呼ばれることもある）は、重要な役割を果たしている。

Log-structured Storageの始まりは、簡単に言えば、次のようなことだ。ある日ある人が次のようなアイデアを思いついたのだ。「ファイルとログ、二つ必要なのかな？　ログがあれば十分じゃないか？　ログのようなスタイルをベースにファイル・システムを作れば、二つを一つにまとめられるぞ。」　このアイデアは、新しいものではない。20年前の論文に、こうしたアイデアに基づく実装例がある。

もう少し詳しく、Log-structured File Systemの（当時の）アイデアの背景を見ておこう。

「ほとんどのファイル・システムは、最近アクセスされたブロックを保持する、大きなメモリー・キャッシュを持っている。だから、ほとんどのReadは、キャッシュで解決できる。ディスクから見ると、ディスクのトラフィックの大部分はWriteトラフィックである。ディスクI/Oを高速化するためには、Writeの高速化が重要である。」

「しかしディスクのパフォーマンスは、最終的には、ディスク・ヘッドの移動によって制限される。現在のファイル・システムでは、ブロックの追加には、ファイルとメタデータへの書き出しを含めて、数回のWriteが必要である。そのためには、ヘッドの移動を伴う数回のシークが必要になるのだが、これには、非常に時間がかかる。」

「いい代案がある。それは、ディスクをログとして使うことだ。ログは、先頭（末尾でもいいのだが）だけに、書き込みが行われるデータ構造だ。もしも、ディスクがログとして管理できるなら、ヘッドのシークがなくなるので、極めて効率的になる。「ファイル」は常に、シーケンシャルに追加される。キャッシュ上で、新しいデータは、inodeやdirectory等のメタデータと、一緒にまとめて、大きなブロックに書き出せばいい。これで、ディスクのスループットは、大幅に向上するはず。」

まあ、ざっと、こんな感じである。実際には、いろいろな課題が残されているのであるが、それについては、省略する。下の図は、Log-structured File SystemとUNIX File Systemの比較である。原著者のスライドから借用した。

AuroraとMySQL Cluster

情報が少なくて、AuroraのLog-structured Storageについて、十分に語れないのが残念だが、それについては、情報が集まり次第、おいおいこの場で投稿したいと思う。ここでは、改めて本題のデータベースのScalabilityとAvailabilityの問題に立ち返ろう。

MySQL Clusterは、分散データベースのベスト・プラクティスである"Shared Nothing"アーキテクチャーに基づいて、キーのハッシュ値でデータを分割してshardingする。それは、優れたScalabilityとAvailabilityをもつ、人気の高いオープンソースの分散データベースである。性能も高い。Googleが、社内システムへのSpannerの投入以前は、MySQL Clusterの世界最大規模のユーザーだったこともよく知られている。

ただ、最初に確認したいのは、MySQLとMySQL Clusterは、同じMySQLの名前を冠してはいるが、バージョン番号の系列も違い、内部のSQLエンジンも異なる、別の製品群だと思った方がいい。（MySQLは、SQLエンジンとしてinnodbを使い、MySQL Clusterはndbを使う。）

Auroraは、MySQL Clusterをクラウド化したものではない。また、Amazon RDS for MySQL Clusterというサービスは、今の所、存在しない。もちろん、アマゾンのクラウド上で、MySQL Clusterを動かすことはできるのだが。それは、Amazon RDS for MySQLを使わなくても、手動でMySQLをインストールして動かせるのと同じである。

MySQL Clusterは、MySQL以上に "Monolithic"なシステムである。（そのことが悪いとは限らない）MySQL Clusterでは、キャッシュの利用からデータ・ノードの分割、そのレプリカの作成、クラッシュ時のフェール・オーバー等々と、すべてのことに、MySQL Clusterというアプリケーション自身が責任を負っている。このように、自律的に完結した、完成されたシステムでは、クラウドのサービスを積極的に利用する余地は、あまり残されていないのかもしれない。

AuroraとRAC

商用データベースのScalabilityとAvailabilityでは、OracleデータベースのクラスターのRACが、一つの「頂点」だと言っていい。Oracleのデータベースには、データベース・エンジン単体の機能でも、MySQLにはない機能がたくさん備わっている。MySQLを使おうかRACを使おうかと悩むことは、あまりないだろう。そもそも、価格が、何桁か違うのだから。

ただ、AuroraとRACを比較することは、場合によったらあり得るのではないかと、僕は、楽しい空想をしている。Auroraの最大構成である db.r3.8xlargeのインスタンスを使った時、Auroraは、32のCPUと244Gのメモリーが利用できる。それで一時間 4.64ドルだ。この最大規模のAuroraを、24時間・365日動かしたとしても、かかる費用は、4万ドルだ。ただ、RACのエンタープライズのデータベースの1プロセッサーあたりのライセンス単価は、年間500万円を超える。エンタープライズではなく、スタンダード版だと、その半分にはなる。RACのライセンス料は250万で、これらに年間保守料を上乗せすると、エンタープライズ版のRACでは、1CPUで、900万以上のお金がかかる。スタンダード版のRACで1CPU、500万くらいか。もちろん、それだけでは終わらないのだが、重要なことは、RACを、1CPUで使う人はいないということである。この値段 x CPUの数だけお金がかかることになる。(Oracle「価格表」を参照のこと)

僕は、直接、RACを使ったことはない。ただ、ネットでRACの構成例を色々調べたのだが、メモリーを244Gも積んでいるRACは、見つけることができなかった。32CPU, 244GメモリーのAuroraは、RACに対しても、価格破壊力だけでなく、そのパフォーマンスも強烈なのではと思う。

終わりに

Auroraのインパクトは大きい。クラウドの機能を生かした、クラウド上のデータベースの構築は、これからの大きな流れになって、エンタープライズのシステムを変えていくと思う。

ただ、こうした方向は、エンタープライズの分野では、Amazonだけが追求しているわけではないこともにも留意しよう。僕は、Auroraの一ヶ月ほど前に発表が行われた、MSのAzure SQL Database Elastic Scale にも注目している。

これは、MySQL Clusterのような、クラスター型の分散データベースのクラウド化だ。ここでも、しっかりと、クラウド・サービスの利点が生かされている。MSのElastic Scaleについては、別の機会に詳しく紹介したい。